There are communication applications that allow users to communicate in real time by a communication network such as the Internet. Such applications require each user wanting to participate in a real-time communication to have the communication application installed on his or her terminal and such a user to have an account enabling him or her to be identified with the service provider offering the communication application. Some of these communication applications can be integrated in a web browser but they are installed separately from the web browser. For example, such communication applications are known by the names of Skype™, Facebook™, GoogleTalk™, etc.
All the abovementioned products require downloads, native applications or extension modules (plugins) external to the browser. Now, the downloading, installation and updating of plugins is complex, the source of errors and of inconvenience. Moreover, the design, the testing, the updating and the deployment of plugins is complex and costly.
With the development of the HTML5 (HyperText Markup Language 5) language, new perspectives have been opened up to the developers of applications with the possibility of rendering the interfaces (API—Application Programming Interface) with the web applications accessible in a standardized manner within the browser.
Such is the pathway followed by the IETF and the W3C with the RTCWEB/WebRTC standard which aims to provide two types of specifications:                a protocol specification, carried out at the IETF;        a Javascript API specification, carried out at the W3C.        
The abovementioned two specifications aim to provide an environment whereby a Javascript application incorporated in any web page, read by any compatible browser, and allowed in an appropriate manner by its user, is capable of establishing a communication using audio, video (and auxiliary data), without the platform of the browser limiting the types of application in which this communication functionality can be used.
According to the current RTCWEB/WebRTC standard, a web browser must implement three API interfaces to be able to receive and transmit data in a streaming mode, these APIs are as follows:                MediaStream: allows the browser to access the streams of data such as those from the web cam and from the microphone of the terminal of the user;        RTCPeerConnection: handles audio or video calls, with encryption and bandwidth management mechanisms;        RTCDataChannel: handles peer-to-peer communication for genetic data.        
To obtain more information concerning the RTCWEB/WebRTC specifications, the following documents can in particular be consulted:                WebRTC 1.0: Real-time Communication Between Browsers—W3C Editor's Draft 22 Mar. 2013—accessible on the Internet at the following address:        
http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcpeerconnection-interface                Overview: Real Time Protocols for Browser-based Applications—draft-ietf-rtcweb-overview-06—Feb. 20, 2013—accessible on the Internet at the following address:        
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/
Currently, web browser publishers are offering trial versions of this new service between browsers, for example Google with the Chrome™ browser, Mozilla with the Firefox™ browser, Ericsson with the browser called Bowser™ developed for cell phones.
In the versions offered to date, which conform to the RTCWEB/WebRTC specifications, when a first user wants to establish an audio or video communication, from his or her WebRTC-compatible web browser, with a second user over the Internet, he or she begins by logging on via his or her browser to an application server providing the WebRTC communication service. After a possible authentication operation, the browser loads, via a web page, the web application (Javascript application) conforming to the RTCWEB specifications and adapted to interact with the abovementioned APIs (conforming to the WebRTC specifications) which are natively incorporated in the browser.
Next, the first user chooses, via the web page for connecting to the application server, an identifier of the second user, then enters a command—for example by a click on an action button displayed in the web page open in the browser—to trigger the audio or video call to the second user. Typically, the web page opened in the browser then displays a message indicating that the connection is currently being established.
If the second user, the recipient of the call, is also connected to the same WebRTC communication service provided by the application server, then he or she can accept the audio or video call from the first user, and the communication will then be able to established.
It thus emerges that, for a WebRTC communication to be established between two users, both users have to be connected to the application server. In order to not miss a communication request, the terminal of the called user must then permanently run a web browser thus using resources, and in particular the battery, of the terminal. This can be problematical in the case of mobile terminals.
Furthermore, the called user must be able to be identified by the application server to receive a communication request originating from the calling user. The called user must therefore have an account with the provider of the application server. To request a communication to the called user, the calling user must also know with which provider the user of the called terminal can be reached.
A WebRTC real-time communication service is to be found on the website https://appear.in. This communication service allows a user wanting to establish a WebRTC video communication to obtain a URL pointing to a video chat that can include up to 8 users connected to the chat. The user can then copy the URL obtained in a message and send it to the users with whom he or she wants to communicate. When the other users access the web page to which the URL points, they are connected with the user via the video chat. Such a service requires the user to go and visit the website of the service when he or she wants to establish a communication with other users, create a chat room to obtain the URL, copy the URL into a message and inform the recipients of the message to whom he or she wants to send it. All these steps are tedious for the user, above all if he or she wants to communicate from a mobile terminal.